System and Method for Network Design

ABSTRACT

A method includes accessing network information stored at a remote device, the network information identifying one or more available physical locations to deploy one or more network nodes of a proposed network. The method further includes receiving data indicating a number of core layer nodes to be included in the proposed network. The method further includes determining a number of aggregator layer nodes to be included in the proposed network, the number of aggregator layer nodes determined based on incrementing a threshold number of aggregator layer nodes that supports a coverage area of the proposed network. The method further includes generating a network design of the proposed network. The network design identifies particular physical locations of the one or more available physical locations to deploy each of the core layer nodes and each of the aggregator layer nodes of the proposed network.

CLAIM OF PRIORITY

This application claims priority from and is a continuation of U.S.patent application Ser. No. 12/501,890 filed on Jul. 13, 2009 andentitled “SYSTEM AND METHOD FOR NETWORK DESIGN,” which is a continuationof and claims priority from U.S. patent application Ser. No. 10/751,683filed on Jan. 5, 2004 and entitled “SYSTEM AND METHOD FOR ETHERNETNETWORK DESIGN,” the contents of both are expressly incorporated hereinby reference in their entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates to a system and method for networkdesign.

BACKGROUND

A network may be characterized by several factors like who can use thenetwork, the type of traffic the network carries, the medium carryingthe traffic, the typical nature of the network's connections, and thetransmission technology the network uses. For example, one network maybe public and carry circuit switched voice traffic while another may beprivate and carry packet switched data traffic. Whatever the make-up,most networks facilitate the communication of information between atleast two nodes, and as such act as communications networks.

At a physical level, a communication network may include a series ofnodes interconnected by communication paths. Whether a network operatesas a local area network (LAN), a metropolitan area networks (MAN), awide are network (WAN) or some other network type, the act of designingthe network becomes more difficult as the size and complexity of thenetwork grows. When designing a given network, an operator or providermay decide where to physically locate various network nodes, may developan interconnection strategy for those nodes, and may prepare a list ofdeployed and/or necessary networking components.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration,elements illustrated in the Figures have not necessarily been drawn toscale. For example, the dimensions of some of the elements areexaggerated relative to other elements. Embodiments incorporatingteachings of the present disclosure are shown and described with respectto the drawings presented herein, in which:

FIG. 1 presents a flow diagram for designing an Ethernet Optical Networkin accordance with the teachings of the present disclosure; and

FIG. 2 shows one embodiment of a graphical user interface and systemthat incorporate teachings of the present disclosure to facilitatedevelopment of improved network designs.

DETAILED DESCRIPTION

Given the relative complexity of some communication networks, designersmay invest a great deal of time and money trying to develop a feasibledesign for a given network. A feasible design may be one that satisfiesdesign objectives like network coverage, network availability, andtraffic demands, while taking into account design limiters like definedlimitations on equipment and/or interconnection topology. A systemand/or technique incorporating teachings of the present disclosure mayassist these network designers and provide them with a mechanism for“optimizing” their network designs.

In practice, a designer may use the teachings disclosed herein todevelop more than one feasible design. The designer may determine arelative and/or actual value that indicates which of the feasibledesigns comes closest to an optimal design. In practice, ato-be-developed network may be optimized to one or more criteria. Forexample, a network designer may be most concerned about deployment cost.As such, the designer may use the teachings disclosed herein and attemptto create a network design that defines the lowest cost yet feasiblenetwork. Another designer may be more concerned about sensitivity tolink failures. That designer may optimize to some robustness orredundancy characteristic.

In one embodiment of a method incorporating teachings of the presentdisclosure, embedded network information describing at least oneexisting network element and a plurality of physical locations availablefor locating new network nodes may be received. A demand forecast for acoverage area of a proposed network may also be received. In anembodiment in which a proposed network has at least a core layer, anumber of core layer nodes to be included in the proposed network mayalso be received. In an embodiment in which a proposed network has atleast an aggregation layer, a number of aggregator layer nodes toinclude in the proposed network may be calculated by adding a positiveinteger quantity to a lower bound number of aggregator layer nodes.Consideration may be given to these and other inputs in connection withgenerating a potential network design for the proposed network. Anoptimization value representing robustness of the proposed network ofthe potential network design may also be calculated.

Such a methodology may help network designers develop robust yetaffordable networks in a more timely and less costly manner. Moreover,systems and methods incorporating teachings of the present disclosuremay also allow designers to more readily take into account relativelycomplex network challenges like load balancing, forecast sensitivity,and specific and/or random link failure effects.

As mentioned above in the brief description of the drawings, FIG. 1presents a flow diagram for designing an Ethernet Optical Network (EON)in accordance with the teachings of the present disclosure. Thefollowing description focuses on EON design, but the techniques of FIG.1 and this disclosure could also be used to design other types ofnetworks.

As mentioned above, networks may take several forms. For example, ato-be-designed network may embody a high-speed, fiber-based, Ethernetover Multiprotocol Label Switching (MPLS) network. Using MPLS may allowan operator to integrate Layer 2 information about network links likebandwidth and latency into Layer 3. As such, in an MPLS-based network, anetwork operator may enjoy greater flexibility when routing trafficaround link failures, congestion, and bottlenecks. From a Quality ofService (QoS) perspective, MPLS-based networks may also allow networkoperators to better manage different kinds of data streams based onpriority and/or service plans.

In operation, a packet entering an MPLS network may be given a “label”by a Label Edge Router (LER). The label may contain information based onrouting table entry information, the Internet Protocol (IP) headerinformation, Layer 4 socket number information, differentiated serviceinformation, etc. As such, different packets may be given differentLabeled Switch Paths (LSPs), which may “allow” network operators to makebetter decisions when routing traffic based on data-stream type.

Technique 10 of FIG. 1 may begin at step 12, where a network designermay launch a network design tool. The tool may be local to a computerbeing accessed by the user. It may also be remotely located at a server,for example, and the user may access the tool from a local client. Atstep 14, embedded network information may be inputted to the tool. Theembedded network information may describe at least one existing networkelement. It may also describe a collection of physical locations atwhich the designer may locate new network nodes. In some embodiments,the step of inputting embedded network information may involvecontacting a repository maintaining the information. For example, alocal computer may access remotely located TIRKS and/or EMS data togather the embedded network information to be inputted.

At step 16, a design parameter may be input into the tool. For example,a network designer may want the tool to take into account a forecasteddemand for the to-be-designed network, a price list for equipment to beincluded in the to-be-designed network, a design limitation forequipment to be included in the to-be-designed network, a number ofnodes, some other design criteria, and/or a combination thereof.

At step 18, additional information may be input into the tool. Thisinformation may include for example a number of core layer networknodes. A designer may be using the tool to design an Ethernet OpticalNetwork that has an access layer near the customer edge, and aggregationlayer where access layer traffic is combined, and a core layer wheremuch of the traffic communicated between different aggregator layernodes is routed. The tool may be able to generate a “better” design morequickly if it is “told” how many core layer nodes to include and whereto locate them.

At step 20, a lower bound number of aggregator layer nodes may becalculated. The lower bound number may be calculated in severaldifferent ways. For example, if a network designer has some idea of theto be designed network's forecasted traffic demands, the designer maydetermine the lower bound by taking the total traffic and dividing it bythe capacity of a given aggregator node. The resulting number mayrepresent a theoretical minimum number of aggregator layer nodes.However calculated, the lower bound number of aggregator layer nodes mayvery rarely be attainable.

As such, at step 22 a user-defined or system defined value may be addedto the lower bound to present a more “realistic” number of potentialaggregator layer nodes. The value may be zero in some cases. In othercases, the value may be an integer greater than zero. Whatever thevalue, a number of aggregator layer nodes to be deployed may be inputinto the tool at step 24. At step 26, the tool may consider the numberand location of core nodes, the number of aggregator nodes, and anyinput design parameters to generate a first potential network design. Atstep 28, additional potential network designs may be generated.

In one embodiment, each of the different designs will include anaggregator node located in a different available location. The differentdesigns may also differ from one another in other ways. For example, onedesign may include the input number of aggregator nodes while otherdesigns may increment that value and include more or less aggregatornodes. At step 30, an optimized value for each of the designs may becalculated. If, for example, the designer seeks the lowest cost network,the optimized value may represent a total cost of deployment for eachnetwork. If the designer is more concerned with robustness, theoptimization value may be associated with the robustness of the proposeddesigns.

Whatever the network design is being optimized to, at step 32 the“better” network design may be identified. At step 34, a proposednetwork report may be output. The network report may include variouscombinations of information. For example, the report may include a list,cost, and location of line cards to be installed in embedded equipment;a list, configuration, cost, and location of to be installed networknodes; a port-level connection report detailing how to interconnect thevarious network nodes; a total cost of deployment; an implementationschedule; and/or combinations of these and other information types.

As mentioned above, a network designer employing a technique liketechnique 10 to design a network may be able to work remotely from aserver or computing platform executing instructions that effectuatetechnique 10. In such a system, the remote computing platform mayinclude a computer-readable medium containing computer-readableinstructions capable of instructing the platform to access embeddednetwork information, to access a proposed number of core layer nodes fora network, to access a number of proposed aggregation layer nodes forthe network, to consider a forecasted demand for the network, and togenerate at least two potential network designs for the network.

The remote computing platform may also be able to identify a lower costnetwork from the at least two potential network designs. In operation,the platform may initiate presentation of a graphical user interface ata local and/or remote display that includes a field for receiving a userinput defining the number of proposed aggregation layer nodes. In somesystems, a computer-readable medium may maintain additionalcomputer-readable data capable of directing a computing device toinitiate retrieval of embedded network information from a remoterepository. The remote repository may include a Trunk Inventory RecordKeeping System (TIRKS®) and/or a network Element Management System(EMS).

In light of the potential authority granted to a remotely locateddesigner, a system incorporating teachings of the present disclosure mayelect to use some rights management technique. For example, the systemmay employ a security engine, which could include an authenticationengine and an authorization engine. The authentication engine may beable to compare an initial set of credentials received from the remotedesigner against a maintained set of credentials. The credentials mayinclude, for example, a user name and password combination. If thereceived credentials match the maintained credentials, the authorizationengine may grant access to a network design tool that incorporatesteachings of the present disclosure.

In some embodiments, various pieces of information including networkinformation may be communication to and/or requested from a designer ina format that allows a graphical user interface to display textualinformation and a visual representation of the to-be-designed network.As mentioned above, FIG. 2 shows one embodiment of a system 50 andgraphical user interface (GUI) 52 that incorporate teachings of thepresent disclosure to facilitate development of improved networkdesigns. GUI 52 may be presented within a display associated with anaccess device 53. GUI 52 may include a browser bar portion 54 and adisplay portion 56. Display portion 56 may contain several activeelements 58, 60, and 62.

In operation, device 53 may include a network interface 64 that can format least a portion of a communication link that spans a network 66 andinterconnects device 53 and remote server 68, server 68 may have anassociated repository 70 that maintains embedded network information.The embedded network information may help a designer attempting to layout a new network design. For example, a designer may seek to develop anEthernet Optical Network 72 employing MPLS. Proposed network 72 mayinclude a core layer 74, an aggregator layer 76, and an access layer 78.As shown, a graphical representation of network 72 may be displayed to auser in GUI element 60. The circles included in the display mayrepresent physical locations available within the network for locatingnetwork nodes. As such, location 80 may represent a place in the networkwhere an aggregator layer node may be deployed.

In the depicted network 72 of FIG. 2, access layer 78 may represent aProvider Edge—Customer Location Equipment (PE-CLE) location. Aggregatorlayer 76 may represent a Provider Edge—Point of Presence (PE-POP)location. The aggregator layer nodes may be MPLS capable and may serveas the LER into the MPLS cloud. In some to-be-designed networks, adesigner may know design criteria for the nodes of the various layers.For example, network 72 may be designed such that aggregator layer nodesdo not connect to one another but are connected to at least two corenodes. Other requirements, preferences, and/or criteria may be inputinto the tool to help ensure that output network designs are feasible.

Whatever the design criteria, a design engine 82 may be capable ofgenerating at least two proposed network designs each including at leastone deployed network node described in the embedded network information.Similarly, an optimization engine 84 may be capable of determining whichproposed network design is optimal or near optimal. If the design isbeing optimized for low cost deployment, optimization engine 84 may actas a costing engine and may be capable of determining a lower costproposed network from the at least two proposed network designs.

To facilitate interaction with the designer, a system like system 50 mayinclude an output engine 86. Output engine 86 may be capable of causingthe presentation of interactive GUI elements like elements 58 and 62. Asshown, element 58 may request an inputting of some design criteria fromthe designer. In the embodiment of FIG. 2, the designer is being askedto input a number of nodes to be included in the proposed network. Thedesigner may respond to the request by populating field 88.

Similarly, element 62 may present the designer with a list of proposednetwork designs in connection with the optimization value for eachdesign. As depicted in FIG. 2, the optimization value may be associatedwith some total cost of the network value. In preferred embodiments, thedisplayed value be presented in hypertext. In response to a designerselecting a given value, device 53 may cause a more detailed networkreport to be presented to the designer.

Many of the above techniques may be provided by a computing deviceexecuting one or more software applications or engines. The software maybe executing on a single computing platform or more than one. Theplatforms may be highly capable workstations, personal computers,microprocessors, servers, or other devices capable of performing thetechniques. It will be apparent to those skilled in the art that thedisclosed embodiments may be modified in numerous ways and may assumemany embodiments other than the particular forms specifically set outand described herein.

Accordingly, the above disclosed subject matter is to be consideredillustrative, and not restrictive, and the appended claims are intendedto cover all such modifications, enhancements, and other embodimentsthat fall within the scope of the present invention. Thus, to themaximum extent allowed by law, the scope of the present invention is tobe determined by the broadest permissible interpretation of thefollowing claims and their equivalents, and shall not be restricted orlimited by the foregoing detailed description.

1. A method comprising: at a computing device: accessing networkinformation stored at a remote device, the network informationidentifying one or more available physical locations to deploy one ormore network nodes of a proposed network; receiving data indicating anumber of core layer nodes to be included in the proposed network;determining a number of aggregator layer nodes to be included in theproposed network, the number of aggregator layer nodes determined basedon incrementing a threshold number of aggregator layer nodes thatsupports a coverage area of the proposed network; and generating anetwork design of the proposed network, wherein the network designidentifies particular physical locations of the one or more availablephysical locations to deploy each of the core layer nodes and each ofthe aggregator layer nodes of the proposed network.
 2. The method ofclaim 1, further comprising determining the threshold number of theaggregator layer nodes that supports the coverage area of the proposednetwork.
 3. The method of claim 1, wherein the threshold number isincremented by a user-defined positive integer.
 4. The method of claim1, further comprising receiving second data indicating a demand forecastfor the coverage area of the proposed network, wherein the proposednetwork has a core layer, an aggregation layer, and an access layer. 5.The method of claim 1, further comprising receiving a price informationof equipment to be included in the proposed network.
 6. The method ofclaim 1, wherein the network information is accessed from a remotenetwork element management system.
 7. The method of claim 1, wherein theproposed network is an optical network.
 8. The method of claim 7,wherein the proposed network is a multiprotocol label switching basednetwork.
 9. The method of claim 1, further comprising determining avalue associated with the network design of the proposed network,wherein the value is associated with a total cost of the proposednetwork.
 10. The method of claim 1, further comprising generating areport associated with the network design of the proposed network, thereport identifies equipment to be deployed based on the network designand a cost associated with the equipment.
 11. The method of claim 1,further comprising generating a report associated with the networkdesign of the proposed network, the report including informationindicating one or more connections of each of the core layer nodes andeach of the aggregator layer nodes of the proposed network.
 12. A devicecomprising: a processor; a memory coupled to the processor, the memorystoring instructions that, when executed by the processor, cause theprocessor to perform a method comprising: establishing a communicationlink with a remote device that stores network information; receivingdata indicating a number of core layer nodes to be included in aproposed network; determining a number of aggregator layer nodes to beincluded in the proposed network, the number of aggregator layer nodesdetermined based on incrementing a threshold number of aggregator layernodes that supports a coverage area of the proposed network; andgenerating a network design of the proposed network, the network designidentifying particular physical locations to deploy each of the corelayer nodes and each of the aggregator layer nodes of the proposednetwork, the particular physical locations determined based at least inpart on the network information.
 13. The device of claim 12, wherein thenetwork information identifies one or more available physical locationsto deploy one or more new network nodes of the proposed network.
 14. Thedevice of claim 13, wherein the method further comprises initiatingpresentation of a graphical user interface that displays a map thatillustrates the one or more available physical locations to deploy theone or more new network nodes.
 15. The device of claim 12, wherein themethod further comprises generating at least one additional networkdesign of the proposed network.
 16. The device of claim 15, wherein themethod further comprises initiating presentation of a graphical userinterface that displays a first cost associated with the network designand costs associated with the at least one additional network design.17. The device of claim 12, wherein the method further comprisesinitiating presentation of a graphical user interface that includes oneor more input controls to receive one or more parameters related to theproposed network.
 18. The device of claim 17, wherein the dataindicating the number of core layer nodes is received via the one ormore input controls.
 19. The device of claim 17, wherein the one or moreparameters includes a design limitation for at least one piece ofequipment to be included in the proposed network.
 20. A non-transitorycomputer-readable medium storing computer-readable instructionsexecutable by a processor to perform a method comprising: accessingnetwork information stored at a remote device, the network informationidentifying one or more available physical locations to deploy one ormore network nodes of a proposed network; receiving data indicating anumber of core layer nodes to be included in the proposed network;determining a number of aggregator layer nodes to be included in theproposed network, the number of aggregator layer nodes determined basedon incrementing a threshold number of aggregator layer nodes thatsupports a coverage area of the proposed network; and generating anetwork design of the proposed network, wherein the network designidentifies particular physical locations of the one or more availablephysical locations to deploy each of the core layer nodes and each ofthe aggregator layer nodes of the proposed network.